1. Field of the Invention
The disclosure relates to a system and a method for multi-core synchronous debugging of a multi-core platform.
2. Description of Related Art
Many electronic devices use simpler processors as control centers Processors execute software to provide different functions of an electronic device During the process of developing software, a debugger must be used. FIG. 1 shows a conventional debugger, wherein a computer host 110 includes the software portion of the debugger. A target system 150 includes the hardware portion of the debugger and the processor for debugging.
In further detail, the debugger can be split into four layers as shown in FIG. 2. The integrated development environment (IDE) layer 220 is the debugger software executed by the computer host 110, which provides an interface for the user to operate and issue instructions. The driver layer 240 is a software driver located in the computer host 110 and converts the operating instructions of the user to a hardware protocol that is acceptable to the target system 150, such as the Universal Serial Bus (USB). The protocol converter layer 260 is located in the target system 150, and converts the signal from the driver layer 240 to the protocol used by the in-circuit emulator (ICE) layer 280, such as the Joint Test Action Group (JTAG) standard widely used in debuggers. The ICE layer 280 is an ICE located in the target system 150, which handles the debugging functions for the target processor.
During the debugging process, the user can set breakpoints and watchpoints through the user interface of the IDE layer 220, and then order the processor to start executing program instructions. A breakpoint designates the location of a programming instruction, while a watchpoint designates a memory location. The ICE of the target system 150 receives operating instructions from the user, including the setting of breakpoints and watchpoints. Whenever the processor executes the programming instruction designated by a breakpoint or accesses the memory location designated by a watchpoint, the ICE controls the processor to stop the processor from executing program instructions and enter a debug mode. During the debug mode, the user can read statuses of the processor, including contents of the memory and registers through the user interface and the ICE to determine if the program is running as expected and observe the problems if the program does not perform as expected. Through the user interface and the ICE, the user can correct the content of the memory and the register, correct the current breakpoints and watchpoints, or set new breakpoints and watchpoints. After the above actions, the user can issue another command so that the processor continues to execute program instructions in order to begin the next iteration of the debugging.
There is already a trend of multi-core processors. Labs have made multi-core platforms that include ten or more cores, or even a hundred cores, and some multi-core platforms are heterogeneous platforms that include cores of various types. Each core is equivalent to an independent processor, and each core requires an exclusive debugger. If there are twenty cores, this means there needs to be twenty debugger structures as shown in FIG. 2. The computer host 110 needs to execute twenty pieces of debugger software. Twenty user interface windows need to be opened. Twenty signals are required between the computer host 110 and the target system 150. In addition, the target system 150 needs twenty test access ports. This causes the debugger software to be very complicated and is harder to use, and increases the cost. If multiple cores are performing the same task, these cores have to begin the execution at the same time and enter the debug mode at the same time. Because the debug software of each core is respectively independent, and there is a time difference when the user operates the debugging software one by one, the synchronous requirement is difficult to achieve.
Currently there are three solutions for the integration and synchronization between the debugging systems for multi-core platforms.
The first solution is to serially concatenate the signals for all the cores and then input the concatenated signals to a single test access port. This way, all the cores can be controlled through only one testing port.
The second solution is to gather and schedule the operating instructions for debugging at the software level or the hardware level of the debugging system, which enables the cores to synchronously start and stop.
The third solution is to provide a debugging bus connected to each core after the test access port of the target system in order to achieve hardware integration.